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Модель связи структурных свойств онтологии 
со структурой модели требований системы, 

о * 
основанной на редактируемых знаниях 


Предлагается модель связи онтологии, лежащей в основе разработки системы, с набором требований 
к ней. Минимальный набор требований формируется на основе онтологии предметной области и с 
учетом традиционного распределения функций между подсистемами такой системы. Модель обеспечивает 
возможность автоматического формирования таких требований. 


Создание и внедрение экспертных систем выдвинуло проблему технологической 
поддержки разработок в области искусственного интеллекта на передний план [1]. 
Ввиду все возрастающего использования систем искусственного интеллекта в конк- 
ретных приложениях, к ним начинают предъявляться практически те же требования, 
что и ктрадиционным программным комплексам и системам. В связи с этим становится 
весьма актуальной поддержка жизненного цикла разработки этих систем. Как и в случае 
обычных программных систем, разработка системы искусственного интеллекта должна 
начинаться с формулирования полных, непротиворечивых и однозначных требований к 
ней [2]. Таким образом, создание ПО систем, основанных на знаниях, (СОЗ) имеет как 
общие моменты с разработкой традиционных систем ПО, так и свою специфику, кото- 
рая явным образом должна отражаться в соответствующих моделях жизненного цикла. 

Традиционно при разработке СОЗ используется формализованная онтология пред- 
метной области, а сами СОЗ включают в себя типичные архитектурные компоненты, в 
числе которых есть редактор знаний и подсистема решения задач пользователя. Редак- 
тор знаний вместе с базой знаний являются относительно независимой подсистемой, 
ориентированной на своего пользователя — эксперта предметной области и инженера 
знаний. Поэтому функциональные требования к ней могут рассматриваться отдельно от 
требований к остальной части СОЗ, ориентированной на специалиста, решающего зада- 
чи в своей предметной области. 

В статье рассматривается возможность поддержки автоматического формирова- 
ния требований к обеим подсистемам на основе онтологий, лежащих в основе разра- 
ботки системы. 


Постановка задачи 


Формулирование полных, непротиворечивых и однозначных требований начи- 
нается с их явного представления в виде документа. Известно, что учет разных точек 
зрения при создании требований обеспечивает их максимальную адекватность. Важны 
как точки зрения разных участников разработки, так и разные аспекты их представле- 
ния — функциональный, информационный, поведенческий. 


* <“ 
Работа выполнена при финансовой поддержке ДВО РАН, проект «Обеспечение качества 
интеллектуального программного обеспечения в процессе его проектирования на основе онтологий». 
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Онтология предметной области, лежащая в основе разрабатываемой СОЗ, со- 
держит согласованное мнение экспертов, а с другой стороны, охватывает функцио- 
нальный и информационный аспекты анализа требований к программному обеспече- 
нию, разрабатываемому в предметной области. 

В модели онтологии предметной области целесообразно различать две составляю- 
щие — систему понятий знаний (вместе с ограничениями целостности знаний) и систему 
понятий действительности (вместе с ограничениями целостности ситуаций). 

Обе составляющие по форме представления схожи и соответствуют типичным 
представлениям об онтологии, как взаимосвязанной совокупности определений тер- 
минов-сущностей, терминов-связей и онтологических соглашениях об ограничениях 
на их интерпретацию: 


Онтология = ({Сущностьз, {Связь}, {Соглашение„}). 


Часто формальное представление системы понятий знаний и системы понятий 
действительности размещены в разных теориях (модулях) онтологии предметной 
области. Например, для решения задачи построения рентгеновского спектра терминами 
системы понятий действительности являются: источник возбуждающего излучения, 
активность источника, относительная эффективность регистрации, энергетичес- 
кое разрешение, угол падения первичного излучения, угол отбора вторичного излуче- 
ния, количество каналов, коэффициенты калибровки, плотность пробы, толщина пробы 
и др. А система понятий знаний включает: характеристические линии элемента, энер- 
гия характеристического излучения, энергии линий изотопа, сечение возбуждения и др. 

Выделяют также и такую часть модели онтологии, как связь знаний и действи- 
тельности, которая, например, может содержать все формулы, требующиеся для полу- 
чения решения конкретных задач. 

Такое разделение позволяет использовать систему понятий знаний (вместе с огра- 
ничениями целостности знаний) для поддержки формирования требований к редактору 
знаний, а систему понятий действительности и связь знаний и действительности — 
для поддержки формирования требований к подсистеме решения задач. Требуется по- 
лучить модель связи онтологии с набором требований, которые могут быть получены 
исходя из описания предметной области и из традиционного распределения функций 
между подсистемами СОЗ. Прочие требования, если они есть, будут добавлены анали- 
тиком к этому методологически обоснованному набору требований. 

Формальное представление онтологии дает возможность извлекать ее внутреннее 
содержание, структуру и оценивать внутренние свойства, это позволяет построить модель 
связи структурных свойств онтологии со структурой модели требований. Получаемый та- 
ким способом набор требований должен обеспечить «каркас» для их точной спецификации. 


Формирование требований к СОЗ 


Традиционно документ, описывающий требования к программному обеспечению, 
включает в себя такие подразделы (группы требований), как: общие функциональные 
требования, требования к качеству и эксплуатационным характеристикам, описание 
информации, описание поведения, спецификации функций, описание критериев для 
подтверждения и др. 

Общие функциональные требования включают описание предназначения всей 
СОЗ, их написание не является рутинной работой и не требует автоматизации. При- 
мер формулировки для СОЗ, выполняющей построение характеристического рентге- 
новского спектра , таков. «Программная система должна выполнять построение ха- 


' Первая версия разработана в лаборатории интеллектуальных систем ИАПУ ДВО РАН. 
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рактеристического рентгеновского спектра по известным элементному составу про- 
бы и ее геометрическим свойствам, позволять выполнять перемещение по графику и его 
масштабирование, позволять сохранять полученный спектр в файл, позволять до- 
бавлять, изменять и удалять знания, используемые при построении спектра». 

Далее для СОЗ явно указывается (или оно очевидно) распределение общих функ- 
ций по подсистемам, как минимум, по двум — подсистемы для эксперта и для пользо- 
вателя. Например, редактор знаний должен: позволять пользователю просматривать, 
добавлять, изменять и удалять информацию обо всех сущностях, знания о которых не 
зависят от текущего состояния действительности, но используются для решения задач. 
«Построитель» должен: позволять пользователю задавать входные условия задачи, 
решать задачу и обеспечивать удобство при просмотре результатов. 

Более конкретные функциональные требования (типичный минимум для таких 
систем) и описание информации создаются на основе метода анализа структуры онто- 
логий [2], [3]. Требования к качеству и эксплуатационным характеристикам слишком 
мало связаны с моделью предметной области, поэтому к рассматриваемой методоло- 
гии не относятся. Описание поведения мало связано с моделью предметной области, 
но может быть формализовано на основе модели пользовательских задач, которая бази- 
руется на онтологии пользовательских задач. Формализация описания поведения воз- 
можна, но основана на другой онтологии и модели. А описание критериев для под- 
тверждения достаточно легко формулируется при наличии готовых спецификаций 
функций и описании используемой информации. 


Модель для формирования требований к подсистеме 
редактирования знаний. Описание функций 


Наиболее популярный случай определения сущностей в онтологии знаний - их 
описание названием и атрибутами: 


Сущность = (Название, 1[..*{Атрибути). 
Структура соответствующего фрагмента текста онтологии знаний (на языке 
прикладной логики [4]) такова: 


сорт «названиеСущ»: {} п; 


{сорт «названиеАтр»: ( «названиеСущ» —> СтдТип)}, 
где СтдТип — предопределенное множество значений или его подмножество, напри- 
мер, все положительные целые. 

Кроме формального подхода к выявлению атрибутов сущности может быть 
применен анализ смысла названия, а именно: «названиеАтр», как правило, не указы- 
вает на процесс или действие. 

Менее распространены случаи, когда сущность задается только своим назва- 
нием, либо задается как частный случай другой сущности (или подмножество неко- 
торого множества). 

Типичный набор функций для редактора знаний связан с вводом всех таких 
сущностей (составных объектов) и их атрибутов: добавление сущности, добавление \ 
изменение одного или нескольких атрибутов, удаление сущности. 

Модель отображения структуры онтологии на структуру требований включает 
следующую пару (элементы онтологии -— элементы требований). 

Онтология. Сущность = (Название, 1..*{Атрибут;}) 
Требования. 
ФункцииРедактированиеДанных. 
Ф-Добавить-Экземпляр-Сущности<Название>; 
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Вход: Название, 

Выход: обновленная таблица экземпляров сущности; 
Ф-Удалить-Экземпляр-Сущности<Название>; 

Вход: Название, 

Выход: обновленная таблица экземпляров сущности; 
1..*{Ф-Изменить-Атрибут<Атрибут>Экземпляра-Сущности<Название> 

Вход: Атрибут, 

Выход: обновленный набор атрибутов экземпляра сущности; 

} 

Достаточно распространено в онтологии знаний задание агрегирующих связей, 
когда сущность включает в себя набор однотипных частей либо характеризующих ее 
других сущностей: 

Онтология. Связь = (ХарактеристикаИлиЧасть, 
НазваниеСущности, 
1..*{ОблЗначХарактеристикаИлиЧасть ;}), 
здесь 1..* — указывает на кардинальность связи сущности со своей характеристикой 
или частью - «не менее одного». 

В этом случае к набору функций редактора знаний должен быть добавлен ввод 
всех этих компонентов сущностей. 

Обычно в онтологии задаются также свойства этих компонентов (характеристик 
или частей) — так называемые совместные свойства сущности и ее компонента. 

Онтология. Связь = (НазваниеСвязи, (НазваниеСущности, 
ОблЗначХарактеристикаИлиЧасть), ОблЗначСвязи) 


Это требует добавления к функциональности редактора ввода всех «совместных 
свойств» (добавить запись о совместных свойствах, изменить одно или несколько 
совместных свойств, удалить запись). 

Пример. В онтологии знаний вышеупомянутой задачи каждому элементу сопо- 
ставлены «энергетические уровни»: 


сорт энергетические уровни элемента: 
( химические элементы — {}энергетические уровни ). 


Есть также функции, сопоставляющие всем таким парам некоторые действитель- 
ные числа: 
сорт энергия связи: ( {(»: (х химические элементы, энергетические уровни)) 
п(2, у) Е энергетические уровни элемента(т(1, у))} > "(0; +) ) 
сорт скачок поглощения: ( {(»: (Хх химические элементы, энергетические уровни)) 
п(2, у) Е энергетические уровни элемента(т(1, у))} > "(1; +) } 


Модель отображения структуры онтологии на структуру требований включает 
также следующие блоки (вход и выход функций для краткости опустим). 
Онтология. Связь =(ХарактеристикаИлиЧасть, НазваниеСущности, 
1..*{ОблЗначХарактеристикаИлиЧасть }) 
Требования. 
ФункцииРедактированиеДанных. 
Ф-Добавить-Экземпляр-ХарактеристикиИлиЧасти 
<ХарактеристикаЙлиЧасть> Экземиляра-Сущности 
<НазваниеСущности>; 
Ф-Удалить-Экземпляр-ХарактеристикиИлиЧасти 
<ХарактеристикаЙлиЧасть> Экземиляра-Сущности 
<НазваниеСущности>; 
и 
Онтология. Связь = (НазваниеСвязи, (НазваниеСущности, 
ОблЗначХарактеристикаИлиЧасть), ОблЗначСвязи) 
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И 
Онтология. Связь = (НазваниеСущности, 1..*{ХарактеристикаИлиЧасть ;}) 
Требования. 
ФункцииРедактированиеДанных. 
Ф-Добавить-СовмСвойство<НазваниеСвязи> Сущности <НазваниеСущности> 
и Сущности<ХарактеристикаИлиЧасть>; 
Ф-Удалить-СовмСвойство<НазваниеСвязи> Сущности< НазваниеСущности> 
и Сущности<ХарактеристикаИлиЧасть>; 
1..*{Ф-Изменить-Значение-Свойства<НазваниеСвязи> Сущности< 
НазваниеСущности>и Сущности< ХарактеристикаЙлиЧасть>; 


Ограничения на значения сущностей и/или их свойств являются важной инфор- 
мацией при разработке редактора знаний. Онтология знаний и ее раздел «Ограничения 
целостности знаний» позволяет получить эту информацию. 

Каждое онтологическое соглашение является источником функционального тре- 
бования к редактору знаний, если оно содержит в качестве операндов вводимые и из- 
меняемые сущности, атрибуты, характеристики, части, свойства. 

Например, предложение онтологии 


(>: энергетические уровни) орбитальное квантовое число(у) < главное квантовое число 
энергетического уровня(У) 


приводит к необходимости функции контроля вводимой информации в соответствии с 
утверждением: при вводе орбитального квантового числа любого энергетического уров- 
ня электронной оболочки проверить, чтобы оно было меньше главного квантового числа 
электронной оболочки. Такая проверка должна быть активизирована в редакторе вся- 
кий раз, когда вводится новое значение атрибута — орбитальное квантовое число и глав- 
ное квантовое число, чтобы сопоставить с введенными ранее значениями. 

Для анализа очередности активизации функции (чтобы работала в паре с соот- 
ветствующей функцией ввода) важно увидеть в структуре соглашения отдельные опе- 
ранды, а для формулирования функции важен сам текст. Поэтому минимальная модель 
структуры соглашения такова. 

Онтология. Соглашение = Онтология. Соглашение. Текст 
+ Онтология. Соглашение. Операнды 

Онтология. Соглашение. Операнды = {ЗначениеСвойства| ЗначениеАтрибута| 
ЗначениеХарактеристикиИлиЧасти} 

Если есть в соглашениях условия на некоторое данное, то в редакторе при ввод/ 
добавлении/изменении должны быть подфункции, обеспечивающие выполнение этих 
условий. Для каждого отдельно добавляемого данного — своя функция проверки или 
набор подфункций по каждому условию. 

Модель отображения структуры онтологии на структуру требований должна вклю- 
чать следующий блок. 


Онтология.Соглашение = Онтология.Соглашение. Текст + 
Онтология. Соглашение. Операнды 
И 
Операнд,= Атрибут; | ЗначениеХарактеристикиИлиЧасти; 
Требования. 
ФункцииПроверкиДанных. 
Ф-проверить-выполнение-ограничения. 
Вход: Операнд, 
Описание: <Текст>; 
Выход: Вобеап и сообщение пользователю о некорректности ввода. 


Вышеперечисленный (и зафиксированный в модели отображения структуры онтоло- 
гии на структуру требований) набор требований является проверяемым и однозначно по- 
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нимаемым. Такой набор может быть передан аналитиком проектировщику или кодиров- 
щику, он же становится основой для формулирования критериев для подтверждения. 
Этими достоинствами не обладает следующая формулировка требования к редактору, 
созданная вне рассматриваемой методологии: «При нажатии кнопки “Изменить” рядом 
с таблицей “Энергетические уровни электронной оболочки” новые значения (в полях 
ввода) свойств выделенного энергетического уровня выделенной электронной оболочки 
должны быть проверены на корректность с помощью условий, таких как “У каждого 
энергетического уровня орбитальное квантовое число меньше главного квантового числа 
электронной оболочки, которой этот энергетический уровень принадлежит”. Если 
значения корректны, то в базе знаний и в таблице “Энергетические уровни электронной 
оболочки” значения свойств выделенного энергетического уровня выделенной электрон- 
ной оболочки должны быть изменены на указанные. Если значения некорректны, то 
должно быть выведено сообщение о недопустимости указанных значений». Такая фор- 
мулировка оправданна, когда аналитик является и проектировщиком, и кодировщиком, и 
испытателем, т.е. фиксирует требования «для себя». 


Модель для формирования требований к подсистеме 
редактирования знаний. Описание информации 


Если программное обеспечение создается в рамках одной предметной области, 
то ожидается, что все объекты данных редактора знаний присутствуют в онтологии 
знаний. Анализ теоретико-множественных связей между сущностями в онтологии 
знаний (и/или таксономических связей) редактора знаний позволяет сформировать 
описание входных данных для редактора знаний. 

Модель отображения структуры онтологии на структуру требований включает 
следующую пару (элементы онтологии — элементы требований). 

Онтология. Атрибут = (НазваниеСущности, Название Атрибута, ОбластьЗначений) 
Требования. 
Спецификация входных данных. 
Сущность. Название Атрибута. ОбластьЗначений 
Например, на основе фрагмента онтологии знаний 


сорт орбитальное квантовое число: (энергетические уровни — 1/0; +55) ) 
и 
сорт спин-орбитальное связывание: (энергетические уровни — 7[1/2; +09) } 
будут сформированы области определений двух атрибутов сущности «энергетические 
уровни»: 
энергетические уровни. орбитальное квантовое число 
имеет область значений целые числа в диапазоне [0; +05); 
энергетические уровни. спин-орбитальное связывание 
имеет область значений действительные числа в диапазоне [1/2; +) }. 


Модель для формирования требований 
к подсистеме решения задач 


Терминологию, связанную с решением задач, отражают такие части онтологии, 
как система понятий действительности и связь знаний и действительности. Кроме 
того, необходима спецификация задач или класса задач для разрабатываемой СОЗ, 
которая позволяет выделить среди терминов система понятий действительности те, 
что являются пользовательскими входными данными, и те — что выходными. 

Для подсистемы решения задач характерны такие группы функций, как функ- 
ции «вычислительные» и функции «взаимодействия с пользователем». 
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Формирование «вычислительных» функций по онтологии включает два этапа. 
Первый на основе системы понятий действительности дает спецификацию назва- 
ния и входа-выхода функции. 

Например, по предложениям онтологии: 
сорт элементы пробы: химические элементы 
характеристические линии = радиационные переходы 
сорт радиационные переходы: }п 
сорт интенсивность характеристической линии: ( {(›: (х элементы пробы, 
характеристические линии)) п(2, у) Е характеристические линии 
элемента(л(1, у))} > 7[0; +09) ) 
сорт площадь пика: ({(: {бл: (х элементы пробы, характеристические линии)) 
п(2, ") е характеристические линии элемента(я(1, ")}) интенсивность 
характеристической линии(») > 01 > (0; +09) ) 
формируются первичные спецификации двух функций: 
Найти интенсивность характеристической линии 
Вход: 1) элементы пробы: множество подмножеств множества «химические элементы», 
2) характеристические линии: множество подмножеств множества названий 
Выход: интенсивность: Действительное число в диапазоне [0; +00) 
Найти площадь пика 
Вход: Т) элементы пробы: множество подмножеств множества «химические элементы», 
2) характеристические линии: множество подмножеств множества названий 
Выход: площадь пика: Действительное число в диапазоне [0; +00) 
Модель отображения структуры онтологии действительности на структуру требо- 
ваний включает следующую пару (элементы онтологии — элементы требований). 
Онтология. Связь = (НазваниеФункции, 1..*{НазваниеАргумента;} 
Область ЗначенийФункции) 
И 
Онтология. Сущность = (НазваниеАргумента, Область Определения) 
Требования. 
ФункцииВычисления. 
Ф-<НазваниеФункции>. 

Вход: 1..*{( НазваниеАргумента, Область Определения)} 

Выход: (НазваниеФункции, Область ЗначенийФункции) 

На основе модели «связь знаний и действительности» спецификация дополняется 
описанием сути преобразования входных данных в выходные. 

В соответствии с фрагментами вида 

Онтология. Формула = ({Локальная Переменная, ОбластьОпредПеременной,;}, 
НазваниеФункции, ТекстФормулы) 
модель отображения расширяется таким образом: 
Ф-<НазваниеФункции>. 
Вход: 1..*{( НазваниеАргумента, Область Определения)} 
Описание: ТекстФормулы 
Выход: (НазваниеФункции, Область ЗначенийФункции) 


Пример. Система понятий действительности содержит предложение: 
(е1: элементы пробы) (Ш: характеристические линии элемента(®!)) интенсивность ха- 
рактеристической линии(@, №) = содержание элемента в пробе(е]) * инструментальная 
постоянная * относительная эффективность регистрации (энергия характеристического 
излучения(е1, 1) * активность источника * (У(е: энергии линий изотопа (источник воз- 
буждающего излучения)) выход линии (источник возбуждающего излучения, е) * ((се- 
чение возбуждения(е1, №]))(е) * (фактор поглощения(е1, В))(е) + (фактор вторичного воз- 


буждения(е1, №1) (е))) 
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Итоговое требование таково: 
Найти интенсивность характеристической линии 
Вход: 1) элементы пробы: множество подмножеств множества «химические элементы», 

2) характеристические линии: множество подмножеств множества названий 

Описание: (61: элементы пробы) (Ш: характеристические линии элемента(е])) интенсив- 
ность характеристической линии(@1, №) = содержание элемента в пробе(®]) * инст- 
рументальная постоянная * относительная эффективность регистрации (энергия харак- 
теристического излучения(е1, №])) * активность источника * (У(е: энергии линий изотопа 
(источник возбуждающего излучения)) выход линии (источник возбуждающего излу- 
чения, е) * ((сечение возбуждения(е1, №]))(е) * (фактор поглощения(е|1, В))(е) + (фактор 
вторичного возбуждения(е1, В))(е))) 
Выход: интенсивность: Действительное число в диапазоне [0; +00) 


Вместе с вычислительными функциями важно специфицировать и функции 
проверки вычисляемых значений, если в онтологии действительности присутствуют 
соответствующие онтологические соглашения. Модель отображения такая же, как и 
для редактора знаний. 

Пример специфицированной функции: 
Проверить ограничение 8 
Вход: элементы пробы, характеристические линии, используемые как одна пара (т.е. 
второй элемент пары вычислен как функция характеристические линии элемента от 
первого элемента пары) 
Описание: Проверить выполнение равенства: (е|: элементы пробы) (№1: {(у: характери- 
стические линии элемента(е])) интенсивность характеристической линии(е|, у) > 0}) 
площадь пика(е@1, В!) = интенсивность характеристической линии(@1, В!) 
Выход: Бооеап 


Описание интерфейсов с пользователем 


Для взаимодействия конечного пользователя с системой разрабатывается гра- 
фический пользовательский интерфейс, требования к которому включают описание 
сценария решения каждой задачи, а для каждого шага сценария — функции ввода данных 
и управляющих воздействий пользователя плюс функции отображения результатов. 

Функции ввода и проверки данных от пользователя формируются по модели, 
аналогичной модели отображения в требования редактора знаний. 

Пример: 

Ф-Проверить ограничение-на элементы-пробы 

Вход: элементы пробы. 

Описание: Проверить выполнение элементы пробы = © 
Выход: Бод[еап 


Остальные требования формируются с учетом модели задач пользователя. Каж- 
дая задача в этой модели разбивается на линейную последовательность шагов" и воз- 
можное множество альтернативных подпоследовательностей, каждый из «последних» 
также разбивается на линейную последовательность шагов и возможное множество 
альтернативных подпоследовательностей. Шаг здесь — некоторое воздействие пользо- 
вателя через пользовательский интерфейс. В этой модели одинаковые шаги могут пов- 
торяться в одной или нескольких задачах, они должны иметь одинаковые названия. 


' Другой вариант модели задач пользователя — граф сценария или карта диалога, еще один ва- 
риант — блок-схема сценария. 
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Пример фрагмента модели задачи пользователя (здесь — эксперта): 


Вводит некорректные значения СВОЙСТВ НОВОЙ электронной оболочки и нажи- 
мает кнопку «Добавить» 


ИЛИ 


Вводит корректные значения свойств новой электронной оболочки и нажимает 
кнопку «Добавить» 


ИЛИ 


Выделяет в таблице «Электронные оболочки» какую-то электронную оболочку 


и нажимает кнопку «Удалить» 
ИЛИ 
вводит некорректные новые значения свойств выделенной электронной 
оболочки и нажимает кнопку «Изменить» рядом с данной таблицей 
ИЛИ 
вводит корректные новые значения свойств выделенной электронной 
оболочки и нажимает кнопку «Изменить» 
ИЛИ 
вводит некорректные значения свойств нового энергетического уровня 
выделенной электронной оболочки и нажимает кнопку «Добавить» 
ИЛИ 
вводит корректные значения свойств нового энергетического уровня 
выделенной электронной оболочки и нажимает кнопку «Добавить» 
ИЛИ 
Выделяет в таблице «Электронные оболочки» какую-то электронную обо- 
лочку, выделяет в таблице «Энергетические уровни электронной оболоч- 
ки» какой-то энергетический уровень 
и нажимает кнопку «Удалить». 
ИЛИ 
вводит некорректные новые значения свойств выделенного энер- 
гетического уровня и нажимает кнопку «Изменить» рядом с по- 
следней таблицей 
ИЛИ 
вводит корректные новые значения свойств выделенного энерге- 
тического уровня и нажимает кнопку «Изменить» 


Каждый шаг этой модели отображается на две функции требований: одна тре- 
бует от подсистемы обеспечить пользователю очередное состояние интерфейса, дру- 
гая — обработать воздействие пользователя (шаг). 

Например, в последовательности шагов есть шаг: 

Добавить новое свойство выделенной электронной оболочки 

Получим две функции: 

1. Выделить выбранную пользователем строку электронной оболочки в таблице 
«Электронные оболочки», предоставить поля ввода значений свойств, сделать 
доступной кнопку ввода измененных значений. 

2. Обработать воздействие пользователя: 


2-1) 
25) 


5 


проверить новые значения (в полях ввода) свойств выделенной элект- 
ронной оболочки, 

изменить в базе знаний значения свойств выделенной электронной обо- 
лочки должны быть на указанные, 

вывести сообщение о недопустимости указанных значений. 


Введение и рассмотрение онтологии моделей задач позволит построить модель 
отображения фрагментов модели на требования. 
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Заключение 


Разработка систем, основанных на знаниях, производимая в рамках архитектуры 
«редактор знаний — решатель — интерфейс — система объяснения», производится на 
основе технологии, в которой уделено много внимания начальным этапам жизненного 
цикла, и недостаточно внимания — этапам, традиционным для разработки программного 
обеспечения. Однако полнота и однозначность описания требований по-прежнему яв- 
ляются «залогом» качества программного обеспечения, в частности СОЗ. Предла- 
гаемая методология, позволяющая автоматизировать поддержку создания требований, 
добавляет к технологии СОЗ «недостающее звено». В основе этой методологии лежит 
модель связи структуры онтологии знаний предметной области и действительности с 
требованиями к создаваемым системам, решающим задачи на основе этих знаний. 
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О.А. Шалфеева 

Модель зв?язку структурних властивостей онтологий 31 структурою модел! вимог системи, 

що заснована на редагованих знаннях 

Пропонуеться модель зв’язку онтологий, що лежить в основ! розробки системи, з набором вимог до 
нег. Мин!мальний набтр вимог формуеться на основ! онтологй предметно! област! та з урахуванням 
традищйного розподлу функщй миж шдсистемами тако! системи. Модель забезпечуе можлив1сть 
автоматичного формування таких вимог. 


Уе. А. зйаГеуеуа 

'Тве Моде! оЁ ГлиКазсе Бемееп Згисеига! РгорегИе$ Оп 05у апд Ведигетепт Моде! Зегисвиге 
Зучет Вазе4 оп Кпоу[едое?$ Вешо Ее 

ТБе моде] оЁ Ппказе уусь 1$ а Фе Беаг( оРа зует 4еуеортеп! ап4 зузет гедитетепи$ зе 1$ оЁеге4. 
Миипа! гедатеглеп($ зе 1$ Югииае4 оп Фе Ба515 оЁ дотат ап4 ап4 факте шо ассоцп( ша опа] псНоп$ 
Чзытание Бебмееп зибзузет$. ТБе то4е| этуе ап оррогипйу Юг ащютайс гедиитетеп 5 Югиишайоп. 
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